This is an interesting case. We have experimental bleeding into our normal API. I may be ok with this, but @jmao-denver should weigh in. I may be ok with it because it is obvious it is experimental, so yanking the rug later could be ok.

Do you expect the API to change going forward? If not, it could be promoted out of experimental. If it needs baking time, leave it there.

It does need more baking time, especially since we will be adding more capabilities to it very soon. Right now, we only support reading a single parquet file. Going forward, we want to support reading partitioned data, metadata files, etc.

If we allow experimental feature to bleed into the normal API, maybe a factory/helper function s3_instructions(...) is more desirable than forcing the user to use experimenta.s3.S3Instructions directly? At least, when we decide to graduate S3Instructions from experimental, the user doesn't need to change the code, even though code change comes with the territory of using experimental features. But I am OK with it as is. @chipkent your thoughts?

I'd probably lean to what is currently here because it makes very explicit that it is experimental. I would kind of rather force them to change the code because it also forces them to know it is experimental.

If we allow experimental feature to bleed into the normal API, maybe a factory/helper function s3_instructions(...) is more desirable than forcing the user to use experimenta.s3.S3Instructions directly? At least, when we decide to graduate S3Instructions from experimental, the user doesn't need to change the code, even though code change comes with the territory of using experimental features. But I am OK with it as is. @chipkent your thoughts?